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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document is part 2 of a multi-part deliverable covering the IMS/NGN Performance Benchmark, as 
identified below: 

Part 1 : "Core Concepts" ; 

Part 2: "Subsystem Configurations and Benchmarks". 

Part 3 : "Traffic Sets and Traffic Profiles" . 



Introduction 



Part 1 of this technical specification provides a general introduction to the environment in which the benchmark exists. 
Part 2 documents the subsystem configurations, use-cases and design objectives corresponding to them. 
Part 3 documents the benchmark tests through definitions of traffics sets and traffic profiles. 
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Scope 



The present document is for an initial, revision 1.0, release of an IMS/NGN performance benchmark. The metrics 
measured and reported are for performance of this subsystem under a communications application load. 

The benchmark is defined for the IMS/NGN network as a whole, as well as for several subsystems of an IMS/NGN 
network. The benchmark is designed so that nodes composing a subsystem can also be benchmarked alone. 

This multi-part deliverable consists of three parts. TS 186 008-1 [5] contains overall benchmark descriptions, 
architectures, processes, and information models that are common to all specific benchmarking scenarios. 

The present document is Part 2 of the IMS Benchmark definition and contains the IMS and ETSI TISPAN SUT 
subsystem configurations, the specific benchmarking use-cases and scenarios, along with scenario specific metrics and 
design objectives. It also defines the SUT configuration parameters. The present document also contains any required 
extensions to the overall descriptions present in TS 186 008-1 [5], if necessary for the specific scenario. This present 
document also includes an attachment containing any required data or code files. 

TS 186 008-3 [6] defines an initial benchmark test through the specification of a traffic set, traffic-time profile, and 
benchmark test procedure. 

The current architecture and scenarios defined for IMS/NGN Benchmark in the present document include: 

• Control plane of the IMS/NGN architecture. 

• Registration/De-Registration use-case. 

• Session setup/teardown use-case. 

• Page mode messaging use-case. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or non- 
specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 



The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 282 007 (VI. 1.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[2] IETF RFC 3310: "Hypertext Transfer Protocol (HTTP) Digest Authentication Using 

Authentication and Key Agreement (AKA)". 

[3] IETF RFC 3840 (August 2004): "Indicating User Agent Capabilities in the Session Initiahzation 

Protocol (SIP)". 

[4] ETSI TS 183 041 (VI. 1.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Messaging service using the IP Multimedia (IM) Core 
Network (CN) subsystem; Stage 3: Protocol specifications". 

[5] ETSI TS 186 008-1: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS/NGN Performance Benchmark; Part 1: Core Concepts". 

[6] ETSI TS 186 008-3: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS/NGN Performance Benchmark; Part 3: Traffic Sets and 
Traffic Profiles". 

2.2 Informative references 

[7] ETSI TS 124 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Signalling flows for the IP multimedia call control based 
on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 
(3GPP TS 24.228 version 5.14.0 Release 5)". 

[8] ETSI TS 124 247: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Messaging service using the IP Multimedia (IM) Core 
Network (CN) subsystem; Stage 3 (3GPP TS 24.247 version 7.2.0 Release 7)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

arrival distribution: function describing the probability distribution of the interarrival time of events (e.g. messages) 

attempts per second: rate at which scenarios are executed. Depending on the scenario, the actual implementation 
might be Registration Attempts Per Second (RAPS), or Call Attempts Per Second CAPS 

background load: workload applied to an SUT during a benchmark test, for the purpose of consuming SUT resources 
during a benchmark test and changing the traffic intensity at which the capacity of the SUT is reached 

benchmark log: data file containing measurements of SUT performance collected during the execution of a test 
procedure 

benchmark report: documented generated at the conclusion of a test procedure containing the metrics measured 
during the execution of the test and/or computed from the data collected in the benchmark log 

benchmark test: procedure by which a test system interacts with a system under test to measure its behavior and 
produce a benchmark report 
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configuration: specification of a subset of IMS architectural elements and metrics for which collection of benchmark 
tests can be defined 

design objective: probabilistic model of delay and failure requirements for an SUT, associated with a use-case. It is 
specified by threshold values and probabilities for delay and scenario failure 

Design Objective Capacity (DOC): largest load an SUT can sustain while not exceeding design objectives defined for 
a use-case 

DOC overload: condition or part of a load profile, in which the system load exceeds the DOC 

DOC underload: condition or part of a load profile, in which the system load does not exceed the DOC 

duration distribution: function (e.g. Poisson) describing the probability distribution of the duration of an event 
(e.g. a call) 

inadequately handled scenario attempt: scenario attempt which either fails or which exceeds the threshold values 
defined for the use case of which the scenario attempt is an instantiation 

maximum capacity: smallest scenario arrival rate at which the successful scenario rate cannot be increased 

metric: performance measurement of an SUT reported in a benchmark report 

parameter: attribute of an SUT, test system, system load, or traffic set whose value is set externally and prior to a 
benchmark test, and whose value affects the behavior of the benchmark test 

percent registered subscribers: parameter specifying the percent of subscribers with records in the HSS/UPSF that are 
active during the benchmark test 

percent roaming subscribers: parameter specifying the percent of active subscribers who are roaming 

preamble: phase at the beginning of a test procedure during which initialization of the test system and system under 
test is performed 

protocol diagram: diagram depicting a collection of architectural elements as vertical lines, and protocol interactions 
between the elements as directed lines between architectural elements, where the vertical order in which the directed 
lines appear indicate time sequence 

Protocol Implementation eXtra Information for Testing (PIXIT): statement made by a supplier or implementor of 
an lUT (protocol) which contains or references all of the information related to the lUT 

recovery capacity: when a traffic-time profile describes a scenario arrival rate starting at a value greater than maximum 
capacity and monotonically decreasing, the maximum value at which design objectives for the use-case in effect are no 
longer exceeded 

SAPS increase amount: increment by which the average SAPS changes between steps of a profile 

NOTE: Equivalent to system load increase amount. 

scenario: specific path through a use-case, including the sequence of messages exchanged by all agents, and (when 
meaningful) a scenario duration distribution (e.g. the duration of a call) 

EXAMPLE: An example of a scenario is "simple call - succeeded". 

scenario attempt: event of a scenario being initiated by the test system and handled by the SUT 

scenario attempts per second: average number of scenarios that are instantiated by the test system per second 

scenario arrival distribution: probability distribution that governs the arrival times of scenarios during a test phase 

scenario duration distribution: probability distribution that governs the duration of an individual scenario 

scenario percent of system load: relative frequency of an individual scenario within a system load 

simultaneous scenarios: number of scenarios that the test system may allow a single UE to perform simultaneously 

step number: for a profile consisting of a sequence of steps, the number of steps 
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step time: length of time, in a profile consisting of a sequence of steps, at which the average scenario arrival rate 
remains at the same value 

step transient time: parameter representing the time interval, measured from the beginning of a step, for which counts 
of scenario attempts and inadequately handled scenario attempts are not kept 

stir time: parameter representing a period of time in the preamble of a benchmark test in which a system load is run in 
order to allow initial transient conditions attenuate to an insignificant level 

subscriber base: information elements that describe simulated users 

system load: stream of protocol interactions presented to the SUT by the test system 

system load increase amount: increment by which the average SAPS changes between steps of a profile 

NOTE: Equivalent to SAPS increase amount. 

System Under Test (SUT): collection of hardware and software whose performance is measured by the benchmark test 

test parameters: parameters whose values determine the behavior of a benchmark test 

test procedure: specification of the steps to be performed by a benchmark test 

test scenario: specific path through a use-case, whose implementation by a test system creates a system load 

test system: collection of hardware and software which presents a system load to a system under test and collects data 
on the system under test"s performance, from which metrics can be computed 

total provisioned subscribers: number of simulated subscribers with records in the HSS/UPSF 

traffic- time profile: evolution of the average scenario arrival rate over time 

NOTE: It is specified by a scenario arrival distribution and a function of average scenario arrival rate as a 
function of time. 

traffic set: mixture of scenarios whose proportional contributions to traffic are fixed 

use-case: specification of a type of interaction between a test system and a system under test, corresponding to a mode 
of end-user behavior 

NOTE: A use-case is a collection of scenarios. 

EXAMPLE: An example of a use-case is "simple call", which may contain scenarios "simple call - succeeded", 
"simple call - no answer", and others. 

user behavioral model: model that defines the number and rate at which an individual user of an IMS system makes 
scenario attempts 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

%IHS Percent Inadequately Handled Scenarios 

3 GPP Third Generation Partnership Project 

3GPP2 Third Generation Partnership Project-2 

AKA Authentication and Key Agreement 

APS Attempts Per Second 

A-RACF Access - Resource Access Control Facility 

AS Application Server 

ATCA Advanced Telecom Computing Architecture 

BGCF Border Gateway Control Function 

C-BGF Controlling-Border Gateway Function 

CDMA Code Division Multiple Access 

CN Core Network 

CSCF Call Session Control Function 
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DNS Domain Name System 

DO Design Objective 

DOC Design Objective Capacity 

DSLAM Digital Subscriber Line Access Multiplexer 

GSM Global System for Mobile communication 

HSS Home Subscriber Server 

IBCF Interconnection Border Control Function 

I-BGF Interconnect-B order Gateway Function 

I-CSCF Interrogating-CSCF 

IHSA Inadequately Handled Scenario Attempt 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

ISDN Integrated Services Digital Network 

IWF Inter- Working Function 

JAIN Java API for Integrated Networks 

LAN Local Area Network 

MGCF Media Gateway Control Function 

MRFC Media Resource Function Controller 

MRFP Media Resource Function Processor 

NGN Next Generation Networks 

OMG Object Management Group 

PCI Peripheral Component Interconnect 

P-CSCF Proxy-CSCF 

PIXIT Protocol Implementation eXtra Information for Testing 

PSTF Public Switched Telecommunications Network 

QoS Quality of Service 

SA Security Association 

SBC Session Border Control 

SCS Session Control Subsystem 

S-CSCF Serving CSCF 

SGF Serving Gateway Function 

SIMS SIMultaneous Sessions (per user) 

SLF Subscriber Location Function 

SPDF Service Policy Decision Function 

SQN SeQuence Number 

SUT System Under Test 

TEM Telecommunications Equipment Manufacturer 

TISPAN Telecommunications and Internet convergence Services for Advanced Networking 

T-MGF Trunk Media Gateway Function 

TRT Total Round-trip Time 

TS Test System 

UE User Equipment 

UPSF User Profile Server Function 



4 System Under Test (SUT) subsystems 

An IMS/NGN benchmark is required to allow not only a complete IMS network, as depicted in figure 1 of 
TS 186 001 [5], to be benchmarked, but also subsystems of a network corresponding to discrete products that may be 
available from a supplier. To address this requirement in this multi-part deliverable, a series of subsystems are defined, 
which will serve as a System Under Test (SUT) for a benchmark test. IMS/NGN elements that do not appear in a 
subsystem are regarded as part of the test environment, which must be present for a subsystem to function, but which is 
not itself subject to benchmarking. 

The focus of Release 1 of this multi-part deliverable is depicted in figure 1 of TS 186 001 [5]. IMS elements not part of 
this focus are regarded as part of the test environment. In future releases of this multi-part deliverable, more of these 
elements may be incorporated in subsystems, and additional elements may appear in the reference architecture. 
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Table 1 : Subsystems for which benchmarks are to be specified 



IMS/NGN Performance 
Benchmark Subsystem 


Included 3GPP IMS 
Functionality 


Included TISPAN NGN 
Functionality 


Test Environment 
Functionality 


Session Control Subsystem 
(SCS) 


P-CSCF, l/S-CSCF, HSS 


P-CSCF, l/S-CSCF, S- 
CSCF, UPSF 


DNS, access network 
(e.g. SPDF, C-BGF, 
A-RACF, DSLAM, SBC, 
switches, routers) 


HSS/UPSF Subsystem 


HSS 


UPSF 




P-CSCF Subsystem 


P-CSCF 


P-CSCF 


DNS, access network 
(e.g. SPDF, C-BGF, 
A-RACF, DSLAM, SBC, 
switches, routers) 


l/S-CSCF Subsystem 


l-CSCF, S-CSCF 


l-S/CSCF 


DNS, access network 
(e.g. SPDF, C-BGF, 
A-RACF, DSLAM, SBC, 
switches, routers) 


NOTE: The last column of table 1 represents the elements of the test environment. In Release 1 , only benchmark 
configurations with one network are specified; in such a configuration, DNS queries are cached locally, and 
hence have no significant effect on the measured metrics. Similarly in Release 1 , IPv6, network errors, 
andnetwork delays are not specified in benchmarks, and hence have no impact. 



Figure 1 depicts the IMS Reference Architecture. The components of the architecture are the primary building blocks, 
which are either defined by the IMS standard, or defined by external standards and referenced by IMS. The links 
between the primary building block represent reference points over which the building blocks communicate with each 
other. 

The reference architecture is a logical architecture; no mapping of functional elements to hardware or software 
component is mandated. 



Rf/Ro 




Figure 1 : IMS Reference arcliitecture (from ES 282 007 [1]) 

For the purposes of benchmarking, however, certain rules concerning subsystem configurations are required. These 
rules that benchmark measurements taken from equivalent subsystems of different vendors are comparable with one 
another. 
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The general guidelines for defining an SUT configuration are: 

• All of the functional elements of the subsystem must be present in the SUT configuration. 

• All hardware elements used in the implementation of the SUT configuration must be completely enumerated. 

• All the QoS spec measurements defined at the interfaces to the SUT must be collected as specified in the 
benchmark test. 

• All hardware- specific measurements (e.g. CPU utilization, memory utilization, fabric bandwidth) specified in 
the benchmark test must be collected for all hardware elements used in the implementation of the SUT 
configuration. 

• SUT interface characteristics must be specified so that they can be emulated by the test system, including: 

Security (e.g. IPSec, TLS, DTLS, etc.). 

Interface network characteristics (e.g. up and down bandwidth, up and down latency). 

4.1 Session Control Subsystem (SCS) 

The Session Control Subsystem (SCS) consists of the P-CSCF, I-CSCF, and S-CSCF, and HSS/UPSF components, as 
depicted in figure 2. 

A valid SCS configuration consists of the set of x-CSCF building blocks, as well as the database functions HSS/UPSF 
and SLF that support their functionality. The reference points for the SCS are the G^^ reference point between the UE 
traffic generator and the home and visited P-CSCFs, the Mj, reference point between the S-CSCF and the Simulated 
MRFC, the M- reference point between the S-CSCF and the Simulated BGCF, and the test system management 
interface to the HSS/UPSF and SLF databases. 

A SUT for this subsystem may consist of either one or two SCS configurations, to allow benchmark tests to use a 
combination of local and roaming simulated subscribers. 



DNS 



S-CSCF 




Test 
System 



S-CSCF 



"^^ S-CSCF 4(- 




MRFC 



BGCF 



Test Environment 



System Under Test 
Figure 2: SUT topology for SCS 
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4.2 HSS/UPSF subsystem 

This subsystem refers to the HSS (in 3GPP), and to the UPSF (in TISPAN). 

4.3 P-CSCF subsystem 

The P-CSCF consists of the P-CSCF component, as depicted in figure 3. 

A vaUd P-CSCF configuration consists of the set of P-CSCF building blocks. The reference points for the subsystem are 
the Gj^ reference point between the UE traffic generator and the home and visited P-CSCFs, and the M^ reference 
points to the other simulated components (which are part of the TS in in this configuration). 
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System Under Test 
Figure 3: P-CSCF Subsystem 



4.4 S/I-CSCF subsystem 



The S/I-CSCF Subsystem consists of the S-CSCF, I-CSCF, HSS/UPSF, and SLF components, as depicted in figure 4. 

A vaHd S/I-CSCF configuration consists of the set of S-CSCF and I-CSCF building blocks, as well as the database 
functions HSS/UPSF and SLF that support their functionality. The reference points for the subsystem are the M^ 
reference point between the simulated P-CSCF and the S/I-CSCFs. 
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5 Use cases 

The following use cases, and corresponding tests, are currently defined. This section attempts to define a set of basic 
use-cases and further ones can be defined similarly. These newly defined use-cases, or modifications to the ones 
presented here, will have to be described in a similar manner in the test report. 

The differences in use-cases between 3 GPP IMS and TISPAN NGN occur within and between elements that are part of 
the test environment (outside the Systems Under Test configurations required for this release of the benchmark 
scenarios), with respect to this release of this multi-part deliverable. They therefore are not documented as part of the 
following use-cases; in other words, with respect to this release of this multi-part deliverable, there are no differences 
between 3GPP IMS and TISPAN NGN. 

5.1 Registration/de-registration use-case 

Registration is the first use-case that must be employed when using an IMS network. During this operation the UE 
announces its contact location to the home domain registrar in order for the home network to route terminating 
messages towards it. It is performed by an UE when it is turned on. De-registration is the last operation that an UE 
performs before it is turned off and it is used to invalidate the registered contact information. 

Because of security concerns, this operation has to be authenticated and the assigned S-CSCF challenges the UE using 
authentication vectors obtained from the HSS/UPSF. 

During the initial registration the P-CSCF also negotiates a set of security associations with the UE. Future 
registration/deregistration operations performed over these secure channels do not need to further be authenticated as 
the integrity of the messages is protected. 

The registration has an attached expiration timer. Depending on the type of the network (fixed or mobile) and the usage 
patterns, this timer can vary from a few minutes up to one week, and it is negotiated between the UE and the home 
network. Before this timer expires, or when roaming to a new visited network, the UE has to start re-registration 
scenarios. 
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As part of this use-case, after registering, the UE will subscribe to its own registration status at the assigned S-CSCF. 
This subscription will need to be refreshed periodically, similarly to the registration. Unsubscription is not required, as 
the S-CSCF will automatically terminate it on de-registration. To avoid congestion, the notification timing is not strictly 
coupled to events that triggered them, and can have a delay in the order of seconds. The first one is sent shortly after 
subscription, and as a rule, the UE should be ready to respond to notification at any moment during the subscription 
period. 
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Figure 5: Registration/de-registration state machine 

a) Off - In this state the UE does not have any interaction with the environment. 

b) Discovery - The UE is acquiring an IP address and finds the address of the outbound Proxy-CSCF. 

c) Unsecured - In this state the UE is completely attached to the IP layer and it can fully act at the signaling level. 
This state is mainly used to send initial registration intentions. No traffic is to be trusted by the network until 
the UE is authenticated. The UE should not trust incoming signaling until it will attach to a correctly 
authenticated network. 

d) Secured - the UE begun authentication by requesting an authentication challenge. The UE can verify the 
authenticity of this challenge and it creates a Security Association (S A) with the Proxy-CSCF 

e) Secured and Registered - the UE sends the authentication challenge response to the network, indicating the 
location information that it wishes to save. While in this state, as communication is secured, updates can be 
performed without re-authentication. 

f) Secured, Registered and Subscribed - to react to network initiated events regarding the registration status, the 
UE subscribes to its own registration event package. The UE will then receive notifications on changes and it 
can act accordingly. 

For simplification, it is considered that the initial state is unsecured: the UE simulated by the test system already has IP 
connectivity and the Proxy-CSCF addresses are considered as input configuration for the test system. 
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5.1.1 Definition 

The registration/de-registration is the process by which a UE announces, updates or deletes its location information to 
the home domain" s registrar. This operation is authenticated and a secure communication channel for subsequent 
signaling is set-up between the UE and the network. 

5.1.2 Scenarios 

While the scenarios describe actions on the part of the UE, the portion of the signaling path between the UE and the 
complete IMS system outside the System Under Test configuration (outside the dotted line in Figure 1) are simulated by 
the test environment with test system characteristics fixed with stated values. 

5.1 .2.1 Scenario 1 - Successful initial registration without synchronization 

In the initial registration Scenario, the UE indicates its contact information to the home domain registrar. To prevent 
attacks, the home network challenges the UE as part of the Digest AKA (RFC 3310 [2]) process. The AKA 
authentication also offers keying material for securing the communication channels and provides authentication of the 
home-network. It is considered that in this scenario the UE is always accepting the SeQuence Number (SQN) provided 
by the HSS/UPSF and does not trigger synchronization. 

After registering, the UE starts a subscription for its own registration status at the assigned S-CSCF. 

In the figure below, the scenario for a successful initial registration is presented, without SQN (SeQuence Number) 
synchronization. 
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Figure 6: Successful initial registration without synchronization scenario signalling flow 

In figure 6, the signalling flow is taken from TS 124 228 [7] (page 33: figure 6.2-1); TISPAN has endorsed this call 
flow. The discovery and attachment parts have been removed and Security Association has been inserted. 

5.1 .2.2 Scenario 2 - successful initial registration with synchronization 

NOTE: This scenario does not apply to TISPAN networks because of the usage of AKA. 

This functionality of this scenario is similar to the one defined in clause 5.1.2, except that the UE is not accepting the 
SQN provided by the HSS/UPSF and triggers a synchronization. In this process, instead of sending a challenge response 
in the second REGISTER, the UE sends the authenticated new synchronized SQN towards the HSS/UPSF. The 
HSS/UPSF should save this value and new authentication vectors are generated. The UE is then challenged again. 
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Figure 7: Successful initial registration with synchronization scenario signalling flow 
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Figure 7 is similar to figure 6. Additionally, one more REGISTER transaction is required to complete the process, as the 
second REGISTER was used for synchronization and not for authentication. 



5.1.2.3 



Scenario 3 - Re-registration - user currently registered 



To refresh the registration timer the UE must send a re-registration request before the expiration time expires. This 
should be sent either 600 seconds before the expiration time if the registration time was greater than 1 200 seconds, or 
when half the registration time has passed when the registration time was under equal or less than 1 200 seconds. This 
scenario can also be employed at any time during the registration period when the UE intends to update its capabilities 
according to RFC 3840 [3]. 

If a secure channel has been set-up and it is used during this procedure, the S-CSCF does not need to authenticate the 
user and the signalling is presented in figure 8. If the request is not sent through the secure channel then the signalling 
flow is similar to that of the Initial Registration Scenario. 

In figure 8 we have the signaling flow from TS 124 228 [7] (page 33: Figure 6.3-1); TISPAN has endorsed this call 
flow. 
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Figure 8: Re-Registration - user currently registered signalling flow 



Scenario 4 - Re-subscription - user currently registered 



As the subscription might have a different expiration timer as the registration, re-subscription is not necessarily linked 
to re-registration. The process is detailed in figure 9. 
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Figure 9: Re-subscription - user currently registered signaling flow 



5.1.2.5 



Scenario 5 - Re-registration - user roaming 



When the UE is roaming to another visited network, the procedures are similar to those of initial registration. As there 
are no security association set-up with the new P-CSCF, the initial REGISTER request will be authenticated. The 
network will internally take care of the old registration as specified in clause 5.1.2.8, without any UE interaction. 
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5.1.2.6 



Scenario 6 - UE initiated de-registration 



When the UE requires terminating immediately the registration it can do so by issueing a REGISTER request with an 
expiration timer set to "0". The signalHng flow is identical to clause 5.1.2.3. 



5.1.2.7 



Scenario 7 - Network initiated de-registration 



The de-registration process can be triggered also from the network side, as result of an administrative event. To be 
informed about these changes the UE is required to subscribe to its own registration event package at the S-CSCF. 
There is no action required for the UE to perform on this scenario. 

Based on the place where the administrative de-registration event occurs, there are two signalling flows possible 
depicted in the following two figures. Figure 10 is taken from TS 124 228 [7] (page 62: Figure 6.7.1-1) and figure 11 is 
from TS 124 228 [7] (page 66: Figure 6.7.2-1); TISPAN has endorsed this call flow. 
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Figure 10: Network initiated de-registration - event at the S-CSCF - signalling flow 
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Figure 11: Network initiated de-registration - event at the HSS/UPSF - signalling flow 



5.1.2.8 



Scenario 8 - Network initiated de-registration upon roaming or expiration 



Upon roaming, the S-CSCF should send the notification only to the old visited network P-CSCF and this process 
requires no interaction with the UE. 

Upon expiration, the S-CSCF will send the notification to both the P-CSCF and the UE. Again, no interactions with the 
UE are required. 

This scenario is included for completeness, even though there is no way to devise a benchmark test. 
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5.1 .2.9 Scenario 9 - Network initiated re-authentication 

In case that the home network requires a re-authentication of the user before the UE will normally initiate a re- 
registration as a refresh, it can notify the UE of this. The rest of the process is similar to an initial registration. 

In the notification, a new expiration timer is set to a shorter period. If the UE fails to re-authenticate in this interval a 
normal Scenario 8 for expiration is triggered. 

This scenario is included for completeness, even though there is no way to devise a benchmark test. 

5.1.3 Scenario failures 

Failures to perform these use-case scenarios and failure scenarios (e.g. user unkown, user not allowed to roam, etc.) are 
not described here and are out of scope for the benchmark. Before running the test, the tester will make sure that there 
will be no failures of the SUT as result of bad provisioning. Test System generated traffic. Test Environment issues, 
etc., such that an ideal SUT will always be able to remain in the desired scenario execution path. All failures that will 
happen during the normal run should be exclusively as the result of SUT malfunctions. 



5.1.4 SUT topology 



The internal elements of the topology are not mandated and can be freely chosen from the multitude of options for 
clause 4.1. The only indication is that the entry point in the System Under Test can be represented by one or many 
P-CSCFs. 

5.1.5 Subscriber base 

The subscriber base for the SUT is detailed in a separate XML Schema Definition file provided together with the 
present document (SubscriberBase.xsd). In the following paragraphs, the input parameters for this generator are 
explained. 

As the Successful Initial Registration without Synchronization scenario could be employed to test the maximum number 
of subscribers accepted by a SUT, it is difficult to indicate a maximum limit for this value. Accordingly, the second 
choice for provisioning the data is to be employed. 

Input parameters for the data generators: 

• Realm - All the public and private identities will use the same realm. It must be a correct domain name of 
length Realm.Length. 

• Subscribers. Count - the required subscriber count. This number should be generated from the test procedure 
indications. 

• Subscriber - Each Subscriber contains exactly one private identity and exactly one attached public identity. 

PrivatelD: 

■ Identity - A valid user identity composed of the following: 

Username - a valid username string with a length of Privateld.Identity.MinLength to 
PrivatelD. Identity. MaxLength characters with an equal distribution. It is acceptable that short 
usernames will have a limited number of distinct values. In the case that this limit is achieved 
for several username lengths, the rest of the usernames should have an equal distribution 
between them. 

Domain - equal to the Realm value. 

■ Algorithm - the authentication algorithm that this user employs. 

■ K - the secret key for this user. 

■ OP - the operator specific OP value for this subscriber. 
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PublicID: 

■ Identity - A valid SIP URI composed of the following: 

Username - a valid username string with a length of Publicld. Identity. MinLength to 
PublicID. Identity. MaxLength. The same rules apply as on the Privateld. Identity. 

Domain - equal to the Realm value. 

IDMapping: 

PubHcID. 

■ PrivatelD. 

In table 2 the recommended values for this test are indicated. Changes to these values should be provided in the Results 
Report. 

Table 2: Recommended values for successful initial registration without synchronization scenario 



Name 


Value 


Realm. Length 


16 


Realm 


imsbenchmark.org 


Subscriber.Count 


To be determined based on test procedure indications 


PrivatelD. Identity. MinLength 


4 


PrivatelD. Identity.MaxLength 


16 


PrivatelD. Identity.AcceptableChars 


abcdefghiiklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 


PrivatelD.AIgorithm 


Digest-AKAv1-MD5 


PrivatelD. K 


0x6162636465666768696a6b6c6d6e6f70 


PrivatelD. OP 


0x00000000000000000000000000000000 


PublicID. Identity.MinLength 


4 


PublicID. Identity.MaxLength 


16 


PublicID. Identity.AcceptableChars 


abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZOI 23456789 



5.1 .6 Metrics and design objectives 

The following metrics need to be collected (see TS 186 008-1 [5] for details on the metrics): 

Table 3: Metrics and IHS cases specific to Scenarios 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice as 
metric 


PX TRT- 
REG1 


Between message 1 and 1 1 


Yes, if > 2s 


float 


Processing time of first 
register transaction must be 
under 2 seconds 


PX TRT- 
REG2 


Between message 14 and 23 


Yes, if > 2s 


float 


Processing time of second 
register transaction must be 
under 2 seconds 


PX TRT- 
DNS1 


DNS query 3 


No 


float 


Account for DNS latency 


PX TRT- 
DNS2 


DNS query 4 


No 


float 


Account for DNS latency 


PX CRT 


TRT-REG1 +TRT-REG2 


No 


float 


Total register transaction 
processing time - without 
key processing time 
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Table 4: Metrics and IHS cases specific to clause 5.1.2.2 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
REG1 


Between message 1 and 11 


Yes, if > 2 s 


float 


Processing time of first 
register transaction must be 
under 2 seconds 


PX TRT- 
REG2 


Between message 14 and 23 


Yes, if > 2 s 


float 


Processing time of second 
register transaction must be 
under 2 seconds 


PX TRT- 
REG3 


Between message 25 and 34 


Yes, if > 2 s 


float 


Processing time of third 
register transaction must be 
under 2 seconds 


PX TRT- 
DNS1 


DNS query 2 


No 


float 


Account for DNS latency 


PX TRT- 
DNS2 


DNS query 15 


No 


float 


Account for DNS latency 


PX TRT- 
DNS3 


DNS query 26 


No 


float 


Account for DNS latency 


PX TRT- 
REG 


TRT-REG1 + TRT-REG2 + TRT- 
REG3 


No 


float 


Total register transaction 
processing time - without 
key processing time 



Table 5: Metrics and design objectives specific to clause 5.1.2.3 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
REG1 


Between message 1 and 9 


Yes, if > 2 s 


float 


Processing time of register 
transaction must be under 
2 seconds 


PX TRT- 
DNS1 


DNS query 2 


No 


float 


Account for DNS latency 



Table 6: Metrics and design objectives specific to clause 5.1.2.4 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
REG1 


Between message 1 and 4 


Yes, > 2 s 


float 


Processing time of register 
transaction must be under 
2 seconds 



5.2 Session set- up/tear-down use-case 

This use-case corresponds to a normal 2-party call. The "session set-up" part refers to the establishment of the call and 
the "session tear-down" to its destroyal. Before this scenario is performed, the respective User Endpoints which belong 
to the particular SUT domain and involved in the communication have to be successfully registered/re-registered. The 
registration period must not during execution of this use-case (it is acceptable to do a re-registration refreshment during 
a call scenario). 

This version of the document covers several call scenarios that are encountered the most in a real life deployments: 

• Call Successful. 

• Call Failed (e.g. terminating party not found). 

• Call Abandoned (e.g. originating party cancels the call during ringing, before the terminating party answers). 

• Call Rejected (e.g. the terminating party rejects the call while busy). 

Then several situations for the User Endpoints can been considered, based on the IP-CAN resource reservation status on 
the two participating sides. For example the originating and/or terminating party might require resource reservation or 
they could already have the resources preallocated, before the start of the scenario. 
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In case that the Access Network is not part of the SUT, the IP-CAN reservation steps should be simulated by fixed 
delays in the Test System and the Test Report must contain this values. 

In all successful call scenarios defined in the next subchapters, the signaling flow of the tear-down part is depicted as 
initiated on the terminating side of the call. When generating traffic, the Test System should also simulate the 
symmetric case when the originating user initiates the tear-down and the Test System should maintain a 1 : 1 ratio 
between the two cases. 

During these scenario there are several waiting times during which the Test System must pause, like the ringing time or 
the call hold time. Distribution of these delays can follow a constant or a Poisson distribution. 



5.2.1 



Definition 



Session set-up/tear-down is the scenario in which a multi-media communication session is set-up is attempted between 
two users, of which at least one is an IMS one. During the set-up period a "ringing" delay is introduced and if the set-up 
is successful then the scenario is put on hold for the duration of the call and then it is terminated with a tear-down 
sequence. 

5.2.2 Scenarios 

5.2.2.1 Scenario 1 - Successful call - resource reservation on both sides 

In this scenario both users are registered. The signaling flow is presented below. 
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Figure 12: Successful call - resource resevation on both sides 
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5.2.2.2 Scenario 2 - Successful call - no resource reservation on originating side 

In this case only the terminating party needs to reserve resources as the originating one is considered to have them 
already. 
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Figure 13: Successful call - no resource reservation on originating side 
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5.2.2.3 Scenario 3 - Successful call - no resource reservation on the ternninating side 

The signaling for this case is very similar to the one for a Successful Call with reservation on both sides. 
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Figure 14: Successful call - no resource reservation on the terminating side 
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5.2.2.4 Scenario 4 - Successful call - no resource reservation on either side 

This is the simplest scenario for a successful call and it is similar to a normal SIP call. 
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Figure 15: Successful call - no resource reservation on either side 
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5.2.2.5 Scenario 5 - Successful call - resource reservation on originating side and 

non-IMS terminating side 

In this case the originating user will reserve resources after the call is answered. The terminating user is non-IMS and it 
is put on hold until a re-INVITE is transmited with indication on the resources reserved. 

To simulate the non-IMS user the Test System will initiate a call to an open destination on itself. The Request-URI will 
be filled with this IP address and port number. 
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Figure 16: Successful call - originating user reserves resource and non-IMS terminating user 

5.2.2.6 Scenario 6 - Successful call - no resource reservation on originating side and 

non-IMS terminating side 

The signaling for this scenario is similar to the ones in clause 5.2.2.4. The difference is in the non-IMS terminating user 
and as such the special conditions from clause 5.2.2.5 apply. 
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5.2.2.7 Scenario 7 - Successful call - originating side non-IMS and resource 

reservation on terminating side 

Here the originating side is non-IMS and the Test System should open separate address and port and should contact the 
SUT through the I-CSCF entry point. 
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-14. 200OK- 



UE2 



-3. INVITE- 
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-1 1 . ACK- 



-12. BYE- 



IS. 200 OK- 



i 



Figure 17: Successful call - Originating user non-IMS and resource reservation on terminating user 

5.2.2.8 Scenario 8 - Successful call - originating side non-IMS and no resource 

reservation on terminating side 

The signaling for this scenario is similar to the ones in clause 5.2.2.4. The difference is in the non-IMS terminating user 
and as such the special conditions from clause 5.2.2.7 apply. 



5.2.2.9 



Scenario 9 - Abandoned call - resource reservation on both sides 



This scenario illustrates the case when the terminating user does not answer the phone in the ringing time and the 
originating user abandons the call. The first part of the call, including the resource reservation is similar to the 
successful call scenario. 
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Figure 18: Scenario 9 - Abandoned Call - Resource reservation on both sides 

5.2.2.10 Scenario 10 - Abandoned call - no resource reservation on originating side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.2. 

5.2.2.1 1 Scenario 1 1 - Abandoned call - no resource reservation on terminating side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.3. 

5.2.2.12 Scenario 12 - Abandoned call - no resource reservation on either side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.4. 

5.2.2.13 Scenario 13 - Abandoned call - resource reservation on originating side and 
non-IMS terminating side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.5. 
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5.2.2.14 Scenario 14 - abandoned call - no resource reservation on originating side 
and non-IMS terminating side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.6. 

5.2.2.15 Scenario 15 - Abandoned call - originating side non-IMS and resource 
reservation on terminating side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.7. 

5.2.2.16 Scenario 16 - Abandoned call - originating side non-IMS and no resource 
reservation on terminating side 

This scenario can be derived from clause 5.2.2.9 by applying the similar signaling as in clause 5.2.2.8. 

5.2.2.17 Scenario 17 - Rejected call - resource reservation on both sides 

This scenario illustrates the case when the terminating user refuses the call after the ringing time. The first part of the 
call, including the resource reservation is similar to the successful call scenario. 
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Figure 19: Rejected call - resource reservation on both sides 

5.2.2.18 Scenario 18 - Rejected call - no resource reservation on originating side 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.2. 
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5.2.2.19 Scenario 19 - Rejected call - no resource reservation on ternninating side 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.3. 

5.2.2.20 Scenario 20 - Rejected call - no resource reservation on either side 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.4. 

5.2.2.21 Scenario 21 - Rejected call - resource reservation on originating side and 
non-IMS terminating user 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.5. 

5.2.2.22 Scenario 22 - Rejected call - no resource reservation on originating side and 
non-IMS terminating side 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.6. 

5.2.2.23 Scenario 23 - Rejected call - originating side non-IMS and resource 
reservation on terminating side 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.7. 

5.2.2.24 Scenario 24 - Rejected call - originating side non-IMS and no resource 
reservation on terminating side 

This scenario can be derived from clause 5.2.2.17 by applying the similar signaling as in clause 5.2.2.8. 

5.2.2.25 Scenario 25 - Failed call 

This scenario represents the case when the call fails based on the situation of the involved parties. For example, the 
originating party dialed an invalid number or the terminating party is not registered or the terminating party does not 
exist. Only the case when the terminating party is not found is depicted and similar scenarios can be derived. 



UE1 



IMCN 



-1. INVITE- 



-2. lOOTrying- 



^3. 404 Not Found- 



Figure 20: Failed call 

As it can be observed, only one registered user is required for this scenario. 

5.2.3 Scenario failures 

Failures to perform these use-case scenarios and failure scenarios (e.g. user unkown, user not allowed to roam, etc) are 
not described here and are not in scope for the benchmark. Before running the test, the tester will make sure that there 
will be no failures of the SUT as result of bad provisioning. Test System generated traffic. Test Environment issues, 
etc., such that an ideal SUT will always be able to remain in the desired scenario execution path. All failures that will 
happen during the normal run should be exclusively as result of SUT malfunctions. 
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5.2.4 SUT topology 



The internal elements of the topology are not mandated and can be freely chosen from the multitude of options for 
clause 4.1. The only indication is that the entry point in the System Under Test can be represented by one or many 
Proxy-CSCFs plus an Interrogating-CSCF whose IP address is to be determined by DNS queries. 

5.2.5 Subscriber base 

The subscriber base for the SUT is detailed in a separate XML Schema Definition file provided together with the 
present document (SubscriberBase.xsd). To generate reference data, a data-generator is also available. In the following 
paragraphs, the input parameters for this generator are explained. 

The data definition for this use-case extends the one of the Registration/De-Registration use-case, as the actors involved 
usually need to be registered before performing any call scenario. 

Additionally, several external URI to be used on scenarios with non-IMS actors are defined here. The host parts should 
be DNS configured to point towards the Test System. 

Additionl input parameters for the data generators: 

• ExternalRealm. Length - All the non-IMS actors will have the hostname of this length. 

• ExternalRealm. Count - the required realm count. This number should be generated from the test procedure 
indications. 

• ExternalSubscriber - Each subscriber contains exactly one private identity and exactly one attached public 
identity. 

PublicID 

■ Identity - A valid SIP URI composed of the following: 

Username - a valid username string with a length of Publicld. Identity. MinLength to 
PublicID. Identity. MaxLength. The same rules apply as on the Privateld. Identity. 

Domain - equal to one of the ExternalRealm value. 

In table 7 the recommended values for this test are indicated. Changes to these values should be provided in the Results 
Report. 

Table 7: Recommended values for the session set-up/tear-down use-case 



Name 


Value 


ExternalRealm. Length 


16 


ExternalRealm. Count 


128 


ExternalSubscriber. PublicID. Identity.MlnLength 


4 


ExternalSubscriber.PubliclD.ldentity.MaxLength 


16 


ExternalSubscriber. PublicID. Identity.AcceptableChars 


abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZOI 23456789 
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5.2.6 Metrics and design objectives 

The following metrics need to be collected (see TS 186 008-1 [5] for details on the metrics). 

Table 8: Metrics and IHS cases specific scenario 1, 2, 3, 4, 5, 6, 7, 8 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice as 
metric 


PX TRT- 
SES1 


Session setup time (between 
caller sending INVITE and first 
callee receiving ACK) 


Yes, if > 8 s 


float 


Session setup time must be 
under 8 s, not including 

the ringing time 


PX TRT- 
SES2 


Session initiation transversal time 
(between caller sending INVITE 
and callee receiving INVITE) 


Yes, if > 2 s 


float 


Galled party must get 
INVITE in less than 
2s 


PX TRT- 
REL1 


Between first BYE sent and 
corresponding 200 OK 


Yes, if > 2 s 


float 


Time to release the 
resource must be less than 
2s 



Table 9: Metrics and IHS cases specific scenario 5 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 


INVITE and re-INVITE cost 


Yes, if > 4 s 


float 




The global session 


SES3 


(between caller sending first 
INVITE and callee receiving the 
second ACK) 








establishment must be faster 
than 4 s 



Table 10: Metrics and IHS cases specific scenario 9, 10, 11, 12, 13, 14, 15, 16 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
SES4 


Between caller sending INVITE 
and caller receiving first 200 OK 


Yes, if > 8 s 


float 


Session setup time must 
be under 8 s, not 
including the ringing time 


PX TRT- 
SES5 


Between caller sending CANCEL 
and caller receiving 
corresponding 200 OK 


Yes, if > 1 s 


float 


Call resources must be 
released in less than 1 s 



Table 11: Metrics and IHS cases specific scenario 17, 18, 19, 20, 21, 22, 23, 24 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
SES6 


Between caller sending INVITE 
and caller receiving 486 Busy 
Here 


Yes, if > 8 s 


float 


Session abandon time 
must be under 8 s, not 
including the ringing time 



Table 12: Metrics and IHS cases specific scenario 25 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
SES7 


Between caller sending INVITE 
and caller receiving 404 Not 
Found 


Yes, if>1s 


float 


Call resources must be 
released in less than 1 s 



5.3 Page-mode messaging use-case 

Page-mode messaging is the simple use-case when a message is exchange between two peers. This simple messaging is 
often referred as page-mode messaging, as defined in TS 124 247 [8] and TS 183 041 [4]. This kind of communication 
makes sense when a small number of messages are exchanged between 2 peers. 

A normal call setup and tear-down is often too complicated for transmitting small data quantities. It takes a minimum of 
5 SIP messages and typically 7 for a normal session setup and tear-down. If the application does not require relating 
between messages at the protocol level, simple messaging can be more efficient, employing just 2 SIP messages. 
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Each UE can emit MESSAGE requests towards another UE. To this it can attach data in the form of the Content-Body. 
This data can be in any arbitrary format, the type can be indicated in the Content-type header and the length in the 
Content-Length header. If the whole message exceeds the MTU of the transport layer (usually around 1 500 bytes), 
because of fragmentation, it will be relayed not over UDP, but TCP. 

5.3.1 Definition 

Message exchange is a scenario in which a message is transmited between two peers over the IMS network. 

5.3.2 Scenarios 



5.3.2.1 



Scenario 1 - Successful message exchange 



In this scenario, it is considered that both users are registered and the message will be relayed successfully. The 
terminating party will always respond with a success response. 
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Figure 21 : Signaling flow for message exchange (from TS 124 228 [7] page 532: Figure 10.6-1) 

5.3.2.2 Scenario 2 - Unsuccessful message exchange - called user not found 

In this scenario, it is considered that the destination is either not registered or not existent. In both cases, the signalHng 
flow is the same. Only the originating party of the TS is involved in this scenario. 
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Figure 22: Signaling flow for unsuccessful message exchange 
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5.3.3 Scenario failures 

Failures to perform these use-case scenarios and failure scenarios (e.g. user unkown, user not allowed to roam, etc) are 
not described here and are not in scope for the benchmark. Before running the test, the tester will make sure that there 
will be no failures of the SUT as result of bad provisioning, TS generated traffic. Test Environment issues, etc., such 
that an ideal SUT will always be able to remain in the desired scenario execution path. All failures that will happen 
during the normal run should be exclusively as result of SUT malfunctions. 

5.3.4 SUT topology 

The internal elements of the topology are not mandated and can be freely chosen from the multitude of options for 
clause 4.1. The only indication is that the entry point in the System Under Test can be represented by one or many 
Proxy-CSCF. 

5.3.5 Subscriber base 

The subscriber base for the SUT is detailed in a separate XML Schema Definition file provided together with the 
present document (SubscriberBase.xsd). To generate reference data, a data-generator is also available. In the following 
paragraphs, the input parameters for this generator are explained. 

The data definition for this use-case extends the one of the Registration/De-Registration use-case, as the actors involved 
need to be registered before performing any messaging scenario. 

There is no additional data required. 

5.3.6 Metrics and design objectives 

The following metrics must be collected (see TS 186 008-1 [5] for details on the metrics). 

Table 13: Metrics and IHS Cases for clause 5.3: "Page-mode Messaging Use-Case" 



Metric 
Name 


Description of Metric 


IHS case ? 


Type 


Reason for choice as 
metric 


PX_PMM 
Data Size 


Number of characters of text in 
page mode message 


No 


integer 


Defined in TS 186 008-3 [6] 
as part of benchmark test 
traffic set and traffic-time 
profile 



Table 14: Metrics and IHS cases specific to clause 5.3.2.1 : "Successful Message Exchange" 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice 


PX TRT- 
PMM1 


Between message 1 and 13 


Yes, if > 2 s 


float 


Message transmission 
latency from UE1 to UE2 


PX TRT- 
DNS-Q 


DNS query 3 for l-CSCF 


No 


float 


Test environment metric for 
collection 


PX TRT- 
ULQ 


HSS/UPSFquery5forUE2 
Location 


No 


float 


SUT metric for collection 



Table 15: Metrics and IHS Cases specific to clause 5.3.2.2: 
Scenario 2 - Unsuccessful Message Exchange - Called User Not Found" 



Name 


Additional note 


IHS Case ? 


Type 


Reason for choice as 
metric 


PX TRT- 
PMM2 


Between message 1 and 8 


Yes, if > 2 s 


float 


Message transmission 
latency from UE1 to UE2 


PX TRT- 
DNS-Q 


DNS query 3 for l-CSCF 


No 


float 


Test environment metric for 
collection 


PX TRT- 
ULQ 


HSS/UPSFquery5forUE2 
Location 


No 


float 


SUT metric for collection 
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